Hypertext Transfer Protocol (HTTP) Streaming refers to the process of using HTTP for streaming media. HTTP runs on top of Transmission Control Protocol/Internet Protocol (TCP/IP) and was not designed for streaming media (audio/video) which has a continuous time base. Real Time Streaming Protocol (RTSP) together with Real-time Transport Protocol (RTP) is better suited for streaming media. One of the main differences between HTTP and RTP protocols is the entity that controls the data transfer rate:                HTTP: HTTP is a pull protocol. Data transfer rate is controlled from the client side when using HTTP. HTTP runs on top of TCP/IP, which has its own congestion control/flow control mechanism. This configuration results in an HTTP stream being sent from the server to the client at the available bandwidth.        RTP: (RTP) is a push protocol used for streaming media data. Thus, in the case of streaming media using RTP, the server controls the flow and rate of data transfer. Typically the server sends the data at the bitrate of the media stream.        
In spite of the superiority of the RTSP/RTP protocols for streaming media, HTTP protocol is often used for streaming media data. Traditionally on the Internet, a user who wants to serve streaming media content has easy access to an HTTP server, however, RTP/RTSP servers are not as ubiquitous as HTTP servers. Also, in earlier days, the main mechanism for client connectivity to the Internet for the majority of the users was through a modem. Modems typically supported network speeds of 14/28/56 Kbps. The behavior of HTTP protocol in situations where the available client bandwidth is limited, such as with traditional telephone-line modems, is acceptable for streaming media with bit-rates comparable to the available client bandwidth. As an example a RealAudio stream of 20 Kbps can be streamed reasonably well using HTTP protocol for a client with 28.8 Kbps modem.
With the proliferation of broadband connections to the Internet and high-speed wired/wireless home networks, HTTP streaming, as used currently, has some problems. Let us consider a WiFi 802.11b home network, which can support bandwidths ranging from 1 Mbps to 11 Mbps. Let us consider the case of using HTTP streaming for streaming MP3 audio. The MP3 bit-rates can range from 32 Kbps to 320 Kbps. If HTTP streaming is used to stream the MP3 audio, then typically the HTTP client will end up pulling the data from the HTTP server at a rate much faster than the actual MP3 song bitrate.
The currently existing HTTP streaming clients use one of the following two approaches:                Approach 1: The HTTP client pulls data from the HTTP server at its available client bandwidth. The client media player buffers the data as it arrives. The buffered data is used for playback at the correct playback speed, which is equal to the actual media bitrate.        Approach 2: The HTTP client uses the TCP receive window as a parameter to do the flow control which can throttle the speed of transmission. The TCP sending side stack can have, at any time, several unacknowledged segments sent on the network before it stops and waits for the receiver to acknowledge the first segment. The TCP sender has a knowledge about the TCP receiver's “receive window size” which is the amount of available space in the receiving side buffer for this TCP connection. Using its knowledge about the receive window size and number of unacknowledged bytes sent, the sender stack stops sending data when it calculates that the receiver buffer is full. The receiver updates its receive window size field with each ACK sent back. When the sender sees that the receiver stack has free buffer space available it will again start sending the data.         Thus some HTTP streaming clients let the receive side buffer be filled using the available client bandwidth, but read the data (e.g. using recv( ) socket function) in the client application periodically based on the set client bandwidth preference. RealOne player with the preference “Connection Bandwidth” set to a lower number than the actual available bandwidth behaves this way.        
Both of the above approaches have the following drawbacks:                The first approach requires a very large client side buffer if the available network bandwidth is much larger that the actual media bitrate.        The second approach relies on TCP flow control to achieve streaming. This approach can perform poorly. This is because:                    Pause functionality cannot be efficiently supported without data transfer on the network or an additional proprietary protocol on top of HTTP. This is because the client can not indefinitely set its receive window size to zero to pause the TCP stream. If this is done the server side application will start returning non-success on send operations once the sender side TCP stack reaches its TCP send buffer size for this TCP connection. After a certain number of unsuccessful send( ) function calls the server application is likely to abort this connection. Thus the HTTP client will typically continue to receive the stream and buffer the stream while the user has paused the stream. Pause functionality is important for streaming media.            Exact behavior and performance of this approach is dependent on the particular TCP algorithm implemented by the client side For example the TCP on the client side may be TCP Reno/Tahoe/Vegas or other TCP variations like Delayed ACK algorithm, Fast Recovery algorithm, etc., all of which behave differently.            Exact behavior and performance of this approach is also dependent on the particular TCP stack implementation. This includes various parameters like buffer space available, etc., which are especially important for an embedded device acting as a client.            Relying on TCP receive window size to do rate control for streaming media could result in silly window syndrome. Silly window syndrome results in the receiving side stack sending several ACKs with small windows size updates back to the sender. This can result in the sender sending small TCP segments as the receive window space becomes available. This is typically detrimental to network performance in general.            Some receiving side TCP stacks, especially for embedded systems may not support setting the receive buffer size programmatically (typically setsockopt function with SO_RCVBUF option). The TCP stack will still perform the flow control as before but if the maximum receive window size is small, performance will suffer further and the network overhead will be larger.                        
The use of Approach 2 results in frequent congestion, which requires the client to stop playback and buffer the stream before starting the playback again, resulting in a poor user experience.